Microsoft Lync Server 2010 : Planning for Deploying External Services - Firewall Configuration (part 2)

4. Publicly Routable Perimeter Network

One consideration when planning for Edge services is determining whether the perimeter network contains publicly routable IP addresses. A publicly routable address space is a set of public IP addresses that reach a server directly without any kind of network address translation (NAT). This means public IP addresses are bound directly to the Edge Server network interfaces.

The reason for the publicly routable network requirement is because of how the A/V Edge role uses Interactive Connectivity Establishment (ICE), Session Traversal Utilities for NAT (STUN) and Traversal using Relay NAT (TURN) to facilitate media traffic between endpoints that might be masked by NAT, such as two users at home behind their own routers.

Without delving into too many of the technical details, this requirement comes from the fact that to make the media path work where clients cannot contact each other directly, they must have some middle ground where they can both send to. That middle ground is the public IP address space. Without following the publicly routable address requirements, the environment is susceptible to situations where media transfer follows a nonoptimal path or completely fails if clients cannot contact each other directly.

When Office Communications Server 2007 was released, it was a requirement to have a publicly routable address space for the external A/V Edge Server interface. In Office Communications Server 2007 R2, support was added for using NAT on the A/V Edge Server interface, but NAT could be used only in a scenario with a single A/V Edge Server. If high availability for redundancy was required, using a publicly routable address space was again required.

Lync Edge Servers have the same limitation as Office Communications Server 2007 R2. If a single Edge Server is used, the A/V Edge Server can use an IP address translated by NAT, but if multiple Edge Servers are hardware load-balanced, each A/V Edge Server requires a publicly routable IP address bound to its interface. The only exception to this rule is if DNS load-balancing is used, NAT can be used for all external interfaces.

The Access Edge and Web Conferencing Edge Server roles have never required a public IP address bound directly to their interfaces, but following the same approach selected for the A/V Edge generally makes the deployment simpler. In other words, use private IP addresses and NAT if using NAT for the A/V Edge interface, but if using public IP addresses for the A/V Edge interface, do the same for the Access Edge and Web Conferencing Edge interfaces.

5. Firewall Rules

This section provides a comprehensive list of the firewall rules involved in Edge Server deployments and what features require each of the ports. It also discusses which direction the connections take so that the appropriate ports can be opened inbound or outbound. In some scenarios, the Edge Server initiates the outbound connection to external destinations.

Access Edge Server

The Access Edge Server is the core of any remote access. At a minimum, remote user access must be allowed to the Access Edge Server to support any kind of web conferencing or A/V traffic. Table 1 displays the firewall requirements for traffic between the Internet and the Access Edge Server IP addresses.

Web Conferencing Edge Server

The Web Conferencing Edge Server requires only a single port to be allowed inbound. Additionally, TCP 443 to the Access Edge must already be allowed to support authentication to the web conferences. Table 2 displays the firewall requirements for traffic between the Internet and Web Conferencing Edge Server IP addresses.

A/V Edge Server

The A/V Edge Server has the trickiest set of rules because it varies depending on business requirements. Minimally, to support audio and video traffic with external authenticated users, TCP 443 and UDP 3478 must be allowed inbound to the A/V Edge IP address.

If an organization wants to support A/V federation, the A/V Edge IP address must be allowed to initiate outbound connections to the partner organization. The destination port used by the A/V Edge for outbound federation connections is always within the TCP 50,000–59,999 range. This range is required only for outbound and not required to be opened inbound to support federation with Lync Server or Office Communications Server 2007 R2 organizations.

To support A/V federation to organizations running the original release of Office Communications Server 2007, there are some additional requirements. Both TCP and UDP ranges of 50,000–59,999 must be opened to and from the A/V Edge IP address. Table 3 displays the firewall requirements for traffic between the Internet and A/V Edge Server IP addresses.

Internal Edge Interface

The last set of firewall rules to account for are the ports used by the internal adapter of the Edge Server. TCP 5061 should be allowed from the Edge to the next-hop address to support remote access, federation, and public IM connectivity.

The ports used for signaling are easy to understand, but one detail that might cause confusion is the source IP address to support web conferencing and A/V traffic: It must be allowed from any internal IP address, not just a specific server. Internal endpoints and users contact these ports on the internal Edge Server adapter directly. The server with the Central Management Store should also be allowed to reach the internal Edge adapter on TCP 4443 to push any configuration updates. Wherever referenced in Table 4, Edge Server refers to the internal-facing adapter of the Edge Server.

Figure 5 summarizes all of the rules discussed in the section.

Figure 5. Edge Server Firewall Rules